System and method for optimizing and routing health information

ABSTRACT

A method is disclosed to receive health information request (HIR), including health information request query (HIRQ) and health information request data (HIRD), and to metatag the received HIR. The metatagged HIR is reconciled based on a semantic concept and HIRS is returned.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent ApplicationNo. 61/453,497 by Imran Chaudhri, et al., entitled “Enhanced MedicalInformation Navigation Engine (MINE) System”, filed on Mar. 16, 2011,and is a continuation-in-part of U.S. patent application Ser. No.13/223,228, entitled “MEDICAL INFORMATION NAVIGATION ENGINE (MINE)SYSTEM”, filed on Aug. 31, 2011, by Imran N. Chaudhri, et al., whichclaims priority to U.S. Provisional Patent Application No. 61/379,228,by Ansari, et al., entitled “MEDICAL INFORMATION NAVIGATION ENGINE(MINE) SYSTEM”, the contents of all of which are herein incorporated byreference as though set forth in full.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates generally to healthcare information management andsystems, and particularly to management and reconciliation of healthcareinformation.

2. Description of the Prior Art

In the field of healthcare, a problem has existed and continues to existregarding the reliability as well as disparity of sources of informationthat is often critical to patient care among other reasons. The sourcesof information each employ a unique coding system or subset of a codingsystem to define concepts, diagnoses, measurements, observations, andthe like. When an actor in a medical system receives new information (or“data”) from an event, the question for the medical system is “Wheredoes this data fit in?” The actor must, problematically, make aninference to determine which action to pursue.

Therefore, what is needed is a method and apparatus for reconcilinghealthcare information in a manner that is reliable and usable to thosein the healthcare field, including patients.

SUMMARY OF THE INVENTION

To overcome the limitations in the prior art described above, and toovercome other limitations that will become apparent upon reading andunderstanding the present specification, the present invention disclosesa method and a corresponding structure for optimizing and routing healthinformation.

Briefly, a method and system for optimizing (translating, augmenting,filtering and further optimizing) health information and routing(returning, storing and/or forwarding) it with support for wiki-basedcrowd-sourced quality control of information. The goals of this systemare to make health information more useful and actionable for increasingrevenue, care quality and patient safety, reducing costs and minimizingoperational risks of organizations and individuals using healthinformation to manage health (e.g. EHR user, systems, and patients).Information that comes into the system is routed to the organizationsand/or individuals or their systems as needed after performing theoptimizations required or requested.

These and other objects and advantages of the invention will no doubtbecome apparent to those skilled in the art after having read thefollowing detailed description of the preferred embodiments illustratedin the several figures of the drawing.

IN THE DRAWINGS

FIG. 1 shows a medical system 10, in accordance with an embodiment ofthe invention.

FIG. 2 shows further details of the MINE 12 of FIG. 1, in accordancewith an embodiment of the invention.

FIG. 3 shows an exemplary embodiment implementing the system 10 usingvarious devices.

FIGS. 4 a and 4 b show a flow chart of a process for managing healthcareinformation, in accordance with a method of the invention.

DETAILED DESCRIPTION OF THE VARIOUS EMBODIMENTS AND METHODS OF THEINVENTION

In the following description of the embodiments, reference is made tothe accompanying drawings that form a part hereof, and in which is shownby way of illustration of the specific embodiments in which theinvention may be practiced. It is to be understood that otherembodiments may be utilized because structural changes may be madewithout departing from the scope of the invention.

Referring now to FIG. 1, medical system 10, in accordance with anembodiment of the invention. The system 10 is shown to include medicalsource 14, a medical information navigation engine (MINE) 12, andmedical information consumers (also referred to herein as “output” or“medical output”) 17. The medical source 14 are shown to include anelectronic health record (EHR) 18, EHR 20, health information exchange(HIE) 22, and a picture archiving and communication system (PACS) 24.The MINE 12 is shown to include interface 13, a back-end medicalprocessor 16, and a front-end medical processor 15.

Healthcare information request (HIR) 21 is received from the medicalsource 14 by the MINE 12 and healthcare information request query (HIRQ)23 and HIRSPS 25 is generated by the MINE 12 and sent as at least a partof the medical information that is sent to organizations and individuals(e.g. EHR user, systems, patients) 17. HIRD is comprised of anycombination of coded medical data (e.g. ICD-9 code 250.00, or bloodglucose measurement CPT code 82962 with measured value 103 on Jan. 1,2010), text (for example, part of a clinical encounter note orconsultation report) or image (such as a scanned colonoscopy report orlab report).

“Medical information”, as used herein, refers to any health-relatedinformation, including but not limited to patient medical records,patient entered information, care team entered information, healthcaredevice generated information, and billing information.

The source 14 generally provides various medical information to the MINE12. For example, the EHRs 18 and 20 each may provide information such asmedical records and billing, the HIE 22 may provide information such asmedical records, and the PACS 24 may provide information such asdiagnostic imaging and reports.

The medical information consumers 17, which may be made of a host ofentities or individuals, such as patients, clinics, medicalinstitutions, health organization, and any other medical-related party,use information that is provided by the processor 15 of MINE 12 and thatcan, by way of example, consist of patients, medical systems, medicalorganization administrators, medical researchers, and/or EHR users. Forexample, user-customized processed medical information is provided bythe processor 15 to a number of users within the medical informationconsumers 17. In this case, the processor 15 generates user-customizedprocessed medical information to a plurality of users, with at least aportion of the user-customize processed medical information beingprovided to each of the users based on the relevancy of the portionbeing provided of each user's specific function or role and each user'sassociated security privileges.

The processor 16, in some embodiments, indexes identifies, maps, andconsolidates medical information, received from the interface 13, andtags this information, and determines to reconcile the taggedinformation. In some methods and embodiments, information that isextracted from images is tagged to enhance recall of search queries.Indexing, at least in part, processes document and converts them intoformats that allows for quick searching across a large collection ofdocuments.

The information in the MINE 12 is encrypted and secure to ensure privacyof sensitive medical information.

It is understood that the sources 14 of FIG. 1 includes merely someexamples of the sources that communicate with the MINE 12 and that othersources, known to those in the field, are contemplated. Similarly, theoutput 17 may be used by those or entities not discussed herein but thatare contemplated and within the scope and spirit of the invention.

The interface 13 serves to receive information that is in various forms,such as but not limited to text, html, CCD, CCR, HL7 and any other typeor format of information. The interface 13 then provides to theprocessors 15 and 16 information, as needed.

The processor 16 receives some of the medical information that theinterface 13 processes and performs certain tasks to process it, such asindexing, semantic meta-tagging, and reconciliation. Indexing takesprocessed documents and converts them into formats that make it easy toquickly search across a large collection of documents. Semanticmeta-tagging embeds information into the medical information that isrelevant thereto and that can be later used to search for certaininformation for the purpose of reconciliation and search, among manyothers.

One aspect of consolidation, reconciliation and de-duplication,generally refers to removing of redundant patient medical records, suchas, multiple records for the same individual appearing as though therecords are for different individuals or multiple data elements that arerecorded similarly but slightly differently in the different sources. Inthis case, the processor 16 recognizes that the records belong to asingle individual or are the same data and just recorded differently andautomatically consolidates them. The patient or a user of the system 10may also manually perform reconciliation. The processor 16advantageously determines whether or not reconciliation is performed.

The processor 16 outputs the indexed, tagged and reconciled informationto the processor 15. The foregoing tasks are a generalization andfurther details of each are provided below.

The processor 15 performs certain tasks on the information provided bythe interface 13 and the processor 16, which include query, search,presentation, and quality checking The output of the processor 15 is theoutput of the MINE 12, or output 17.

The MINE 12, through the processor 15, in some embodiments and methods,invites members of a medical care team to join it thereby allowingdistributed user-organized care teams.

Querying, as performed by the processor 15, is the ability to receive,as input, a free text query, from a user, (i.e., a query without anyrestrictions on the structure)—and converting the free text query intocommands to a medical search engine, such as Medical Lexical SearchEngine and the MATRIX (Medical Application Terminology RelationshipIndeX) Concept Search Engine, using a sophisticated query processingengine optimized to work with medical queries. The results of the searchengine are sent to the presentation display planner—which decides themost relevant presentation given the user's organization and role (e.g.the provider, search query program, a healthcare administrator, a studyadministrator, and the patient). The presentation discussed below,receives such information. In some embodiments and methods, the medicalinformation or user information is processed to suggest relevantqueries.

Search, as performed by the processor 15, is built around the concept ofZero-Click Relevance—or the ability to get to all the relevantinformation an actor in the healthcare system requires by typing in justa single query. The search engine, within the processor 15, performingthe search comprises an indexing and searching, as will become apparentshortly. Optionally, search results may be securely embedded into thirdparty programs. In some embodiments, searching involves determiningpresenting (also referred to herein as “providing”) access to specificrelevant data based on a search query, the patient, and the user'sspecific function and/or role and security privileges. A user may bewithin the output 17 and security privileges are either determined bythe MINE 12 or by the patient or both. The information that is uploadedto the MINE 12 by users, such as in output 14 (in some embodiments) issearched by the processor 15. The uploaded information may includeinformation such as but not limited to status posts, records, andimages. Such user-uploaded information is routed automatically to theoutput 17, as needed.

Some aspects of the search are now discussed relevant to an example.Assuming, by way of example, that Dr. Smith, an internal medicinephysician, sees a new patient, Joan Sample, who presents with acomplaint of chest pain. Joan has brought several continuity-of-caredocuments (CCDs) and a 600-page pdf file representing of her medicalchart. She has seen a cardiologist who uses NextGen's electronic medicalrecord (EMR) and a gastroenterologist who uses eMD's EMR and she hasrecently visited a local emergency room. Dr. Smith uses the search ofthe various methods and embodiments of the invention to efficientlyassemble the relevant information he needs. Dr. Smith selects JoanSample as the patient and enters the clinical context “chest pain” inthe search bar of a screen presented by the MINE 12 (examples of suchscreens are shown in subsequent figures herein). He is presented withrelevant lab results, such as CKMB, troponin, and amylase; relevantdiagnostic results, such as prior electrocardiograms (EKGs) and the mostrecent chest computed tomography (CT) scan; and all progress notes andconsult reports in which concepts relevant to chest pain, like “GERD”and “cardiac stress test”, are mentioned. Two distinct types of searchesare combined, in accordance with a method and embodiment of theinvention, to retrieve information medically relevant to Joan'scomplaint: 1) Lexical search, where text in the patient record issearched for occurrences of the search term, its variants and synonyms;and 2) Medical concept search, where data that is medically related tothe search term is retrieved. Medical concept search finds relevantstructured data with standardized codes, such as lab results, and textresults, such as progress notes, which include terms medically relatedto the search term. In Joan's case, a search for “chest pain” returns aCKMB lab result and a reference to the most recent chest CT scan.Accordingly and advantageously, the Lexical and Medical concept searchsolves Dr. Smiths' information overload problem by returning informationin the chart most relevant to determining the etiology of Joan's chestpain complaint. Further, in some embodiments, the presentation,discussed shortly, presents a united view of Joan's history byreconciling and de-duplicating data from multiple sources that may becoded and described differently. Redundant data is automaticallyreconciled even if it is described differently by differently sources.

Presentation, as performed by the processor 15, is displaying healthinformation to the requesting user in a way that reduces the number ofclicks and maximizes the amount of meaningful information deliveredbased on the interpreting the intent of the user query.

Quality checking, as performed by the processor 15, is checking of thequality of medical information provided by various sources, i.e. source14, by the patients, structured data, and unstructured data, in aWiki-like mannered setting whereby the users can help maintain andimprove the quality of information displayed. The foregoing tasks,performed by the processor 15, are further described in detail below.Additionally, the users or patients may make comments regarding medicalinformation, in a Wiki-like manner.

In summary, the MINE 12 transacts medical information including theinterface 13 receiving medical information from a number of medicalsources (such as within the source 14) for processing, identifying,mapping, and consolidating by the medical processor 16, providing accessto specific relevant data, based on a user's security privileges, withinthe identified, mapped, and consolidated medical information, based onuser-specific functions or roles, performed by the processor 15, andgenerating user-customized processed medical information to a number ofusers, such as within the output 17, with at least a portion of theuser-customized processed medical information being provided to each ofthe users based on its relevancy to each user's specific function orrole and each user's associated security privileges.

FIG. 2 shows further details of the system 10, particularly the MINE 12thereof. That is, the processor 16 is shown to include an indexing andmetal tagging module 34, which includes an indexing module and a metatagging module (both of which are not shown in FIG. 2 in the interest ofclarity), which may be a module, as shown in FIG. 2 or two physicallyseparate modules. The processor 16 is further shown to include areconciliation and de-duplication module 36, which also can be brokenout into two modules, a reconciliation module and a de-duplicationmodule, and a code and semantic mapping module 38, which also may be asingle module or multiple modules. The modules 34, 36, and 38communicate with one another.

The processor 15, in some embodiments, includes display andvisualization 40 executing on one or more servers 38, which may be anysuitable computing engine, similar to the servers 32, including but notlimited to PCs or servers. The display 40 is used to constructpresentation and display information to users, such as the patient'srecords, billing information, and other types of medical information.The display 40, in some embodiments, also performs processing of some ofthe functions of the processor 15.

The foregoing modules may be software programs, executed by a computeror computing engine of suitable sorts, or may be implemented inhardware.

FIG. 3 shows an exemplary embodiment implementing the system 10 usingvarious devices. That is, the medical system 30 is analogous to thesystem 10 and is shown to include the sources 14 coupled to communicate,securely, through the secure communication link 42, to the interface 13.The link 42 may be any suitable communication channel allowinginformation, of various formats and types, to be transferred to theinterface 13 in a secure and encrypted fashion. Exemplary communicationchannels of which the link 42 is made include the Internet, VPNconnections over the Internet, private dedicated digital lines such asT1, T3, E1, E3, SONET, and other fiber optic formats.

The interface 13, in some embodiments, is a software program thatexecutes on one or more servers 32, which can be a server of any kind ofsuitable computing engine, such as personal computer (PC). The servers32 receive secure information through the link 42 from the sources 14.The processor 16, in some embodiments, includes the module 36 and one ormore servers 34, which may be any suitable computing engine, similar tothe servers 32, including but not limited to PCs or servers.

The module 36 and servers 34 perform the tasks discussed above relativeto the processor 16 and the display 40 and servers 38 perform the tasksdiscussed above relative to the processor 15 though these processors mayand often perform additional tasks related to medical information, someexamples of which are presented and discussed below and the rest ofwhich are contemplated and achieve the various advantages, results andfunctions presented herein.

The processor 15, in some embodiments, includes display andvisualization 40 executing on one or more servers 38, which may be anysuitable computing engine, similar to the servers 32, including but notlimited to PCs or servers. The display 40 is used to constructpresentation and display information to users, such as the patient'srecords, billing information, and other types of medical information.The display 40, in some embodiments, also performs processing of some ofthe functions of the processor 15.

As shown in FIG. 3, the servers 32 are coupled to the module 36 and theservers 34, and to the display 40 and the servers 38 and the module 36and servers 34 are coupled to the display 40 and the servers 38.

In some embodiments, the interface 13, servers 32, module 36, servers34, display 40, and servers 38 are remotely located relative to thesources 14 and in some embodiments, remotely located relative to oneanother. Further, they are considered a part of the Internet cloudwhere, performing their tasks in a manner known as “cloud-computing”.However, other manner of achieving the functions and advantages of theinvention, including various other of implementation, not shown in FIG.3 or other figures herein and/or not discussed are contemplated.

FIGS. 4 a and 4 b show a flow chart of a process for managing healthcareinformation, in accordance with a method of the invention. The steps ofFIGS. 4 a and 4 b can be executed by a computer processor or device as asoftware program and the like. For example, using the embodiment of FIG.1, the processors and other structures, such as databases and servers,may be employed to carry out the steps and process of FIGS. 4 a and 4 b.

In FIG. 4 a, at step 102, the HIR is received and metatagged by theprocessor 16 and module 34 of the MINE 12. The metatag step 102 addsdescriptive information to the HIRD of HIR and interprets the data ofthe HIRD in a manner that is suitably precise and processes the data bymedical analytics (metatagging), readily known to those in the art, andsubsequently generates a metatagged HIR (also referred to herein as“HIR1”) for use in the next step 104. The HIR1 includes extractedconcepts and annotations.

In particular, in step 102, text is first extracted from the receivedHIR from, for example, images using optical character recognition (OCR)technology. Then natural language processing is used to identify allhealthcare concepts that are described in any text found in the HIRD.The universe of possible concepts currently includes all known medicalterminologies (as documented, for instance in the NCBO Bioportal) alongwith all concepts and terms that are found in the healthcare dataavailable to the system. As new concepts and terms are identified inincoming text, they are added to the universe of concepts. For eachpiece of text that is related to a concept, all possible associationsare added. Multiple levels of association can be annotated via ahierarchical structure, which can be represented in a number of waysincluding XML. The text is further processed to determine what type ofdocument or document section the text represents, what measurements,dates and other context pertain to the concept and whether the conceptis stated in the negative (for example, “no history of diabetes” wouldyield the negated concept “diabetes”, while “diabetes is controlled”would yield a positive instance of the concept “diabetes.”

Execution of the step 102, in some embodiments and processes, causesmore than 65% of key clinical data to be represented by textual data(including that from images), which is not accessible to computerizedanalytical systems. In order to create an optimal representation of anyhealthcare information (for example, for the purpose of augmenting apatient's problem list, medications list and allergies with other knowninformation about the patient, reconciling these lists into a single setof non-redundant items and then casting these items into therepresentation or coding system most advantageous to the user) it isnecessary to include this textual information. The inclusion of suchtextual data in the translation, augmentation and filtering ofhealthcare data is unique to this system.

Next, at step 104, known data is retrieved. That is, the HIR1, generatedby the step 102, is utilized to retrieve from a system search document,such as the system search document 203 of the U.S. patent applicationSer. No. 13/223,228, filed on Aug. 31, 2011, by Imran Chaudhri, et al.and U.S. Provisional Patent Application No. 61/582,213, filed on Dec.30, 2011, by Imran N. Chaudhri, et al., all data related to the contentsof the HIR1, and generates HIR2 for use at step 106. The HIR2 includesthe HIR1 with all retrieved data appended thereto.

Further, at step 104 additional information is retrieved from one of thestructures of the MINE 12 that is necessary to fulfill the requestcontained in HIR1. The contents of the HIRQ are organized into a queryand submitted to the Query/Search 32 of the MINE 12, to retrieve alldata (both structured, textual and image) that matches the criteriadefined in HIRQ. For example, if the request contained in HIR1 is to beused for a reconciled medication list for a patient identified by the ID12345, a query for all medications relevant to patient ID 12345(including those for other patient IDs that have been identified assynonymous with patient ID 12345) will be issued to the MINE 12. Theresulting medication data, which includes text and images that have beenannotated (see step 102 for a specific annotation process) are returnedto step 104 and are appended to the HIR1, resulting in the HIR2, whichis subsequently passed on to step 106.

At step 106, the HIR2 is used to compute associations between allconcepts. “Concepts” are medical concepts such as medications,allergies, problems and diagnoses, procedures, immunizations,measurements, observations, symptoms and the like.

As described hereinabove, because of the importance of textual data inhealthcare documentation, it is critical to include both structured dataand annotated textual data during the process of reconciling,augmenting, disambiguating, and/or filtering of healthcare data. Theinclusion of such textual data in the translation, augmentation andfiltering of healthcare data is unique to this system.

More particularly, at step 106, computing associations between all knownconcepts is performed by using the HIR2 request from the 104 step,assembling all data items from the data portion of HIR2 into pairs,assigning a degree of association measure between each element in thepair, and then outputting HIR3, which includes the HIR2 with theresulting additional pairings and association measures appended to it,to be used as input in step 108.

At step 106, the MINE 12 retrieves association measures for pairs ofconcepts from the MATRIX, discussed in U.S. patent application Ser. No.13/223,228, and U.S. Provisional Application No. 61/582,213 referencedhereinabove. An association measure is a number between 0 and 100 thatrepresents how medically related the two concepts are: a 0 means thereis no relationship between the two concepts, and a 100 means they aresynonymous (also known as “variants”). Each resulting pair plusassociation measure is appended to the HIR2 object. When all pairs havebeen considered and their associations appended to the HIR2 object, theresulting object HIR3 is passed to step 108.

Before translating, augmenting and filtering data contained in HIR, atstep 106 it is necessary to associate semantic concepts with it, so thatdata can then be reconciled and disambiguated. Also, because inhealthcare, closely related but different concepts may be used bydifferent actors to describe the same observation, patient or finding,it is necessary to have continuous measures of association that can beused in a fuzzy match, rather than exact match, strategy (as will bedescribed below relative to step 114).

In accordance with the foregoing, advantageously, medically relevantmeasure of association between two healthcare concepts is assigned.

Referring still to FIG. 4 a, after the step 106, a determination is madeat 108 as to whether or not the HIRQ is reconciled. If it is determinedthat HIRQ has been reconciled, the process executes step 114 and if not,the process continues to 110. During step 114, HIR3 is processed byusing the HIR2 from the step 106, recursively organizing all data itemsinto groups based on fuzzy matching of the semantic concepts representedby the data and further organizes the items within each group accordingto properties defined in the HIRQ query part of HIR3. In this manner,HIR4 is generated and includes the HIR3 annotated with the resultingorganizational structure from the reconciliation process, to be used at110.

During, the step 114, the data in HIR3 is grouped according to the typeof reconciliation requested in the HIRQ portion of the HIR3 request.Specifically, the request can include a set of explicit rules for fuzzymatching of the data items or can reference default rules at step 114.Rules define how strongly components of each data item must beassociated in order to consider them related enough to be grouped orreconciled. For example, if HIR3 includes a request to create areconciled list of all medications included in HIR3, and furtherspecifies that all medications of the same formulation be groupedtogether regardless of manufacturer, prescription instructions andprescription date, then an exact match on the formulation of eachmedication would be required for inclusion in each reconciled medicationgroup. As each new member of a group is added, the prototypical groupmember is re-evaluated. This prototypical group member is useful forcomputational efficiency in some analytical processes, can be used insome display applications and can be returned as the singlerepresentative of the group in some applications. Further grouping andorganization within the group can then be carried out. For example,exact duplicates of data items from different sources are combined intonew subgroups.

At step 114, if HIR3 requests that different instances of groupedconcepts be considered as separate groups, further grouping might becarried out. For example, the same medication prescribed on separateoccasions could either be placed in a single group or distinct groups,depending on whether HIR3 requests that different instances of the samesemantic concept be separated or combined.

Another example of HIR3 relates to a fuzzy match being requested tocreate a reconciled problem list for a specific patient, where the dataelements of HIR3 include “pneumonia” and “viral pneumonia” concepts. Theassociation measure between these two concepts will be high (i.e. closeto, but less than, 100). If HIR3 requests an exact match, then theresulting problem list will include both “pneumonia” and “viralpneumonia”. If HIR3 requests a close fuzzy match then a single conceptfor the group (including both “pneumonia” and “viral pneumonia”) will bereturned. Once all groupings have been completed, the data is in a formto be organized and all elements at this level are organized accordingto the HIR3 request. For the medication example, all distinctprescriptions for a particular medication formulation can be organizedaccording to time order, prescriber, manufacturer, medication type (e.g.statin, analgesic, antibiotic, etc) or other attribute, as specified inthe incoming HIR3 request.

At 108, the determine as to whether reconciliation is performed or notapplies to the HIR before it is used at the determination 110. Thedecision to reconcile in step 108 may be based on an explicit request toreconcile the data, or it may be implied. Implied actions can beidentified using algorithms that may range from a look-up tocomputational inference via artificial intelligence to advanced machinelearning. These algorithms may also be combined serially or in parallel.An implied request to reconcile could be, for example, if HIR includes arequest to generate a problem list that is compliant with a specificstandards-based format. It may be implicit in that format thatreconciliation be performed to remove redundant items from the problemlist, in which case the system could infer that the reconciliation stepshould be performed.

At 110, a determination is done as to whether translation is needed ornot and if so, the process continues to step 116, otherwise, the processcontinues to 112. At the step 116, translation of the HIR is performedbefore the process continues to 112. The decision to translate at 110may be based on an explicit request to translate the data, or it may beimplied. Implied actions can be identified using algorithms that mayrange from simple look-up to computational inference via artificialintelligence to advanced machine learning. These algorithms may also becombined serially or in parallel.

An implied request to translate could be, for example, if HIR includes arequest to generate a problem list that is compliant with a specificstandards based format. It may be implicit in that format that a certaincoding system be used (such as ICD-9 or SNOMED CT), in which case thesystem could infer that the translation step should be performed toensure compliance with the desired output format.

More particularly, at step 116, the process at step 116 is initiatedwhen the HIRQ includes an explicit request to translate or implies arequest to translate. The step 116 converts medical concepts that arerepresented using one coding system to equivalent or similar concepts inanother coding system. Conceptually, it is like converting words inEnglish to words in another language like Spanish. By ‘coding system’ wemean a systematic categorization or ontology of concepts including butnot limited to the standardized categorization schemes that are widelyused in various medical information sources and consumers of medicalinformation, for example: ICD-9, ICD-10, HCC, CPT, SNOMED CD, RXNORM,UMLS, Loinks

The step 116 is significant because the medical information industry hasevolved to have many coding systems for representing medical conceptsfor different purposes (e.g. billing, case management, prescriptions,epidemiology, quality reporting). Medical Information Sources 14 andconsumers of medical information 17 or processes therein often depend onreceiving information in a specific coding system. For instance, aquality reporting subsystem within an EHR may require ICD9 codes and beunable to process information that is represented in UMLS. The step 116is necessary to achieve the goal of using all of the available medicalinformation, not just that information that happens to already be in theappropriate coding system.

The step 116 is advantageously an automatic, software-driven process. Incurrent practice converting information represented in one coding systemto another is typically driven by human knowledge and experience. Forexample, medical billing systems require concepts to be represented incertain coding systems (e.g. ICD9, CPT). However, CMS requires MedicareAdvantage claims to be submitted in a specialized coding system, HCC. Toreceive payment for caring for these patients, providers must convertthe billing information that is supported by their Medical InformationSources (e.g. EHR, practice management systems) from the typical codingsystems (e.g. ICD9, CPT) to the HCC coding system. Providers accomplishthis by hiring trained human coders to assign HCC codes based on theirown knowledge and experience and the available data for each patient.

Also, at step 116, the translation process is encapsulated as a processthat is separate from the Medical Information Sources themselves. Whilesome Medical Information Sources and Medical Information consumers mayhave some capabilities for converting between certain coding systems,MINE 12 provides comprehensive ability to translate between all majorcoding systems. It is accurately applied in a consistent way for allincoming data, regardless of the source.

Further, step 116 is situated within a larger system, MINE 12, which hasaccess to many records for the patient that the HIRD applies to. Thisinformation could be used to resolve ambiguities. By ambiguity we meanwhen one code in the source coding system could be converted to multiplecodes in another coding system, but the resulting codes in the newcoding system are not equivalent to each other and may even conflict. Byresolving ambiguities we mean selecting only the most appropriatecode(s) given all of the information that is known about the patient.

Additionally, step 116 occurs within a larger system, MINE 12, which hasaccess to many records for many patients. This information could be usedto identify associations between medical concepts in various codingsystems and improve accuracy of translation using machine learningtechniques.

Further, at step 116, significant savings in the cost of developing,maintaining and accurately applying coding systems is experienced. Inthe medical industry the various coding systems are often in competitionfor widespread use. There is no single gatekeeper for these codingsystems. They are updated on different timelines and in different ways.All of this means that maintaining and applying accurate and up-to-dateinformation about all of the various systems is time-consuming,error-prone and costly for the individual source 14 or medicalinformation consumer. Moreover, there is a duplication of effort as eachMedical Information Source or medical information consumer must createessentially the same code. By consolidating at the step 116, andseparating it from the individual health information sources and healthinformation consumers we reduce all of these costs for those entities.

Further, at step 116, a consistent conversion for each set of codes toeach other is realized regardless of the source 14 it can lead toimproved consistency of an individual's health record across differentMedical Information Sources 14. It can also reduce variability forcomparisons across different Medical Information Sources 14, forinstance in the kind of comparisons done by quality reporting systems.

Also, at step 116, a large data set is accessible and this step can beaccurately and appropriately perform than a hypothetical module thatperformed the same function but did not have access to informationbeyond the HIRD. Example are: ambiguity resolution from above,identifying new associations and improving accuracy through machinelearning from above.

At step 116, data is received that will eventually be included in theHealth Information Response (HIRSPS). This could be a metatagged versionof the original Health Information Request Data (HIRD), which iscontained in the Health Information Request (HIRD). Alternatively, itcould be a reconciled data set that combines the HIRD and other knowndata as described in outputs of Reconcile 114. Another input is thedesired coding system, which is contained in the Health InformationRequest Query (HIRQ), which is part of the Health Information Request(HIR). Another input to Translate 116 is the larger set of known data.The output of step 116 is the data that will eventually be included inthe Health Information Response (HIRSPS), represented in the codingsystem that was specified in the HIRQ.

The step 116 converts concepts from one coding system to another usingalgorithms that may range from simple look-up to computational inferencevia artificial intelligence to advanced machine learning. The specificalgorithms used may be customized for different source coding system anddesired coding system pairs. They may also be combined serially or inparallel. The algorithms may or may not make use of publishedcrosswalks, findings in the medical literature, or knowledge that hasbeen learned from aggregated data. They may operate over just the datathat is to be translated or consider the data that is to be translatedin conjunction with additional known data about the patient.

It is noted that after the step 114, the process of FIG. 4 a continuesto 110 and after the step 116, the process continues to 112.

At 112, the determination is made as to whether or not totransform/optimize codes or not and if so, transforming/optimizing isperformed at step 118 on the HIR before it is passed on to and used atthe determination at 120 of the FIG. 4 b. The decision of step 112 maybe based on an explicit request to transform or optimize the data, or itmay be implied. Implied actions can be identified using algorithms thatmay range from look-up to computational inference via artificialintelligence to advanced machine learning. These algorithms may also becombined serially or in parallel.

An implied request to transform or optimize the data could be, forexample, if HIR includes a request to generate a problem list that isoptimized for Medicare

Advantage HCC coding. It is implicit in HCC coding that somerepresentations for semantically identical (or nearly identical)concepts are preferred over other representations. For example, ICD-9code 427.89 (Other specified cardiac dysrhythmias) would havesignificantly lower value to a health system than the closely relatedICD-9 code 427.81 (Sinoatrial node dysfunction). In this case is bothcodes could be used to represent data in HIR, then the system can inferthat the transform/optimize process of step 118 should be performed toensure optimal value of the data to the application that consumes theoutput data object.

At step 118, transformation and optimization is initiated when the HIRQincludes an explicit request to transform/optimize or implies a requestto transform/optimize. It is noted that an implied request to translateis anticipated, for instance, if the request contains an instruction toforward to a particular quality measurement system and the outcome isknown to be better than the outcome will be better if the code set forthat purpose is optimized before forwarding it.

During step 118, further, information that is represented in aparticular coding system can be translated or transformed to a subset ofthat coding system that is likely to result in improved outcomes for adownstream process or set of downstream processes in the health careindustry. “Coding” refers to the translation step 116. “Downstream”process refers to workflow function that must be performed by one ormany medical information sources or consumers of health care information(e.g. submitting claims to insurance companies, reporting qualitymeasures, detecting adverse events involving medication conflicts and/orallergies).

For example, the medical condition ‘diabetes mellitus’ may berepresented using more than 50 individual codes within the ICD9 codingsystem. Even for a case of diabetes that is newly diagnosed or poorlyunderstood there are at least 6 potential codes: 250, 250.0, 250.00,250.01, 250.02 and 250.03. For providers who care for Medicare Advantagepatients, some of these codes result in payment increases to adjust forthe additional cost of treatment for the condition (e.g. 250.0, 250.00).Other codes do not (e.g. 250). The step 118 would in this case convertincoming 250 ICD9 codes to 250.01 and/or 250.03 ICD9 codes, which aremore likely to result in improved outcomes, in this case payments toproviders, for a downstream process, in this case Medicare AdvantageRisk Adjustment. This steps allows all relevant information to be usefulfor downstream process, despite the inherent noise introduced by thevariety of available coding systems and processes of translating betweenthem (e.g. step 116), human-driven translations, translations withinMedical Information Sources). This inherent noise results fromunderlying conceptual discrepancies due to the fact that in the medicalindustry the various coding systems do not match up exactly in terms ofindividual concepts. This inherent noise also results from the fact thatdifferent goals require different levels of detail. For example onereason you might be dealing with this is you might have information thatwas entered in for the purposes of clinical decision-making, like a noteor a problem in an EHR, which was then converted to ICD9. If theoriginal coding system did not include the distinction between type1 ortype2 then at the point of conversion to ICD9 there would be no way tounambiguously map it to a single ICD9 code or even a set of codes thatwould be appropriate for all downstream processes. A decision would needto be made during the conversion: exclude the information, use codes forboth Type I and Type II diabetes, use the general category, or pick oneType. All of these possibilities would result in noise in the form oflost information and/or potential errors depending on how theinformation would later be used. Once the conversion was made, it wouldbe difficult to roll back.

Using diabetes mellitus as an example, for the purposes of thedownstream process of Clinical Decision Support it is very important toknow whether a specific case is type I or type II. For the purposes ofMedicare Advantage Risk Adjustment, however, either type results in thesame payment. Thus, for the downstream process of Clinical DecisionSupport, converting ICD9 250 (category: diabetes mellitus) to 250.00(diabetes mellitus without mention of complication, type II orunspecified type, uncontrolled) or 250.03 (diabetes mellitus withoutmention of complication, type I [juvenile type], uncontrolled) withoutdetailed knowledge about which one is more accurate and/or confirmationby a clinician might be disadvantageous and/or dangerous. On the otherhand, converting 250 to 250.00 or 250.03 might be reasonable andappropriate for the downstream process of Medicare Advantage RiskAdjustment.

Current processes often ignore the possibility that these types of noisemay have been introduced in prior steps. They instead assume that thecode is equivalent to the concept and operate on it as such. (resultingin advantages a1 and a2 and a3 below).

There are some special-purpose systems that do this sort of processingfor a particular outcome (e.g. billing optimization). The differencesbetween our design and those are 1) we have access to more additionalinformation for the individual patient, (resulting in advantage b1below) 2) we have access to additional information aggregated acrossmany patients (resulting in advantage b2 below), 3) we optimize formultiple outcomes (resulting in advantage b3 below), 4) we are separatefrom the Medical Information Source and provide consistent outputsregardless of the Medical Information Source (resulting in advantage b4below). The resulting HIRSPS of this step will be maximally useful for aspecified downstream process. Additionally:

A1) All relevant information is used, regardless of noise that may havebeen introduced due to concept mismatches and/or differences in level ofdetail needed for different purposes. (compared to potential approachesthat exclude codes that are not an exact match)

A2) Reduced potential for errors to be introduced in the interest ofincluding more information (compared to potential approaches thatoperate at the most general level to identify more related concepts)

B1) improved accuracy of conversion in the case of a specific patient orset of patients (e.g. looking at medications to infer which type ofdiabetes is being treated),

B2) Improved accuracy of inferences for anyone, even when we do not haveadditional medical information for an individual patient (e.g. knowledgeof which type of diabetes is more prevalent, knowledge of which types ofmedications are associated with each type of diabetes)

B3) Able to compensate for specific biases in data that are introduceddue to concept mismatches and level-of-detail issues (e.g. knowledgethat 250 is used when the type of diabetes (I or II) is irrelevant tothe task at hand, not truly unknown, suggests that if the information isrelevant for the current optimization we should seek additional detailswithin the patient's medical information which may be represented in adifferent coding system (e.g. medication list).

B4) Savings (see equivalent advantage in the step 116)

B5) Consistency for comparison across Medical Information Sources, forinstance for applying quality measures (strategic example, seeequivalent advantage in Translate, 116)

B6) Consistency when multi-sourced data is aggregated for the purposesof optimizing a downstream process (e.g. reducing noise in order todetect a small signal, as in our work with Stanford where the goal is topredict adverse events as new drugs come to market). This also appliesto step 116.

One input to the step 118 is the data that will eventually be includedin the Health Information Response (HIRSPS). This could be a metataggedversion of the original Health Information Request Data (HIRD), which iscontained in the Health Information Request (HIRD). Alternatively, itcould be a reconciled data set that combines the HIRD and other knowndata as described in outputs of the step 114. This data may be in theoriginal coding system(s) or it may be in another coding system asdescribed in the outputs of the step 116.

Another input is an indicator of the downstream process that the outputshould be optimized for (e.g. Clinical Decision Support, MedicareAdvantage Risk Adjustment, Quality Reporting), which is contained in theHealth Information Request Query (HIRQ), which is part of the HealthInformation Request (HIR). Another input to the step 118 is the largerset of known data.

The output of the step 118 is the data that will eventually be includedin the Health Information Response (HIRSPS), represented in the specificcodes that have been optimized for the downstream process that wasspecified in the HIRQ.

At step 118, concepts are converted and represented in a coding systemthat is all-inclusive to a subset of that coding system that isoptimized for a particular downstream process. This conversion processuses algorithms that may range from look-up to computational inferencevia artificial intelligence to advanced machine learning. The specificalgorithms used may be customized for different downstream processes andfor different coding systems. They may also be combined serially or inparallel. The algorithms may or may not make use of publishedcrosswalks, findings in the medical literature, or knowledge that hasbeen learned from aggregated data, including models of translationprocesses. They may explore the impact of multiple possible outcomes onthe downstream process before producing an outcome. Additionally, theymay operate over just the data that is to be transformed/optimized orconsider the data that is to be transformed/optimized in conjunctionwith additional known data about the patient. An example of ‘exploringthe impact of multiple possible outcomes’ would be sending differentversion of the same information represented in different possible codesets to Pophealth, a publicly, government-supported, referenceimplementation for quality measurement, and identifying the best set viagradient descent or some other machine learning algorithm foroptimization.

After 112, the process continues to 120 where a determination is made asto whether or not graphical user interface (GUI) shall be applied to theHIR at step 128 or not before 122. If this decision is positive, theprocess continues to step 128, otherwise, it continues to 122. Thedecision to move onto step 128 may be based on an explicit request topresent the GUI for wiki-based quality control, user confirmation orother modification by the user, or it may be implied. Implied actionscan be identified using algorithms that may range from simple look-up tocomputational inference via artificial intelligence to advanced machinelearning. These algorithms may also be combined serially or in parallel.

At step 128, information is displayed by the Presentation and QualityChecking of the MINE 12, in a way that it can be understood and acted onby a person via graphical user interface (GUI) elements that are knownin the art (e.g. formatted text, tables, forms, checkboxes, drag anddrop interfaces, drop-down lists). The information thus displayed mayinclude the HIRD that is contained in the HIR and/or outputs of any/allprior steps 102, 104, 106, 114, 116 and 118.

Step 128 offers user involvement in that medical sources 14 and/orconsumers of medical information may have a need or desire for humaninvolvement at certain steps in the process (e.g. diagnosis code changesmay need to be certified by clinicians for legal reasons) and this isenabled, at least partially, by the step 128. Human involvement may benecessary to achieve quality, especially when there is uncertainty,missing information, or gaps in the conceptual information. An exampleis that a system may not yet have a suitable model of when it isappropriate to convert ICD9 250 to ICD9 250.00 or 250.03 at step 118. Inthis situation, at the step 128, the original code and the suggestedconversion is displayed and allowing it to later be confirmed orrejected in by the step 134. This will immediately result in the mostappropriate coding decision according to the human user (i.e. a dataquality improvement). It may also contribute to improving the model atstep 118 by operating on future HIRQs.

At the step 128, the overall process provides support for wiki-basedcrowdsourcing of quality control. “Wiki-based crowdsourcing”, as usedherein, allows multiple trusted users to act on the information (e.g.modify, add, delete, augment, filter) before it is transmitted and/orstored. Changes and authors of those changes are logged to allow forcustomization (e.g. a one of the medical information sources of thesource 14 may accept actions of certain users and reject actions ofothers) and roll-back (e.g. going back to the original coding system).In contrast, the prior art process for quality control in the HealthIndustry is for new documents to be created during each visit. Thesedocuments contain a snapshot of what a particular provider described asthe true state of a patient. The process of constructing this snapshotusually involves some review of information from previous visits (e.g.paper chart review, template population in an EHR). All information,true or erroneous, that is added during a visit remains in the patient'srecord from that time forward. Mechanisms for one doctor to documentcomments on or opinions about information contained in a prior chart istypically limited free text comments in a new snapshot, which may or maynot be found or connected with the original information for futureencounters. There is no support for ongoing discussions about treatmentwithin the patient's health information documents, though it may occurvia other channels (e.g. telephone, email, face-to-face conversationsbetween members of the care team).

Accordingly, quality is improved—errors are removed and MINE 12converges on just that information that stakeholders (members of thecare team, etc.) feel is current, accurate and relevant. Further,efficiency is improved by connecting the dots only needs to happen once,not every time a doctor reviews a chart.

At step 128, data to be displayed (original HIRQ and output fromprevious process in the diagram) is received and processed, as discussedherein. This data includes flags indicating what to display (optionallyoutput in previous steps in the diagram) and instructions about how itshould be displayed (original HIRQ and output from previous process inthe diagram) . . . (how=what kind of action needs to be supported andthe information the user will need to carry out that action . . . e.g.simple confirmation may just be a message, while drag and drop needsindividual elements and how they have been categorized. Input containsboth.)

The outcome of the step 128 is a representation that is visible to auser and supports actions/GUI interactions on elements of thatrepresentation e.g. click, drag, select, enter text, submit.

Exemplary GUI at step 128 is implemented using GUI elements known in theart and listed above. One implementation is described U.S. patentapplication Ser. No. 13/223,228 as “DisplayMerge”.

After the step 128, the process continues to step 134 where actions areinterpreted by users within a GUI such that the sources 14 and consumersof medical information can use them. For example, if a person performsthe action of clicking a checkbox next to a particular code within a GUIpresented at step 128, the processed GUI actions at step 134 may allowor prevent the code from being included in the Health InformationResponse (HIRSPS), the final output of the MINE 12, on the basis ofwhether the result of the action was checking or unchecking the box.

Medical sources and consumers of medical information may have a need ordesire for human involvement at certain steps in the process (e.g.diagnosis code changes may need to be certified by clinicians for legalreasons). Human involvement may be necessary to achieve quality,especially when there is uncertainty, missing information, or gaps inthe conceptual information. Example: the system may not yet have a goodmodel of when it is appropriate to convert ICD9 250 to ICD9 250.00 or250.03 at the step 118. In this situation, at step 128, the originalcode and the suggested conversion are displayed so that it can later beconfirmed or rejected at step 134. This will immediately result in themost appropriate coding decision according to the human user (i.e. adata quality improvement). It may also contribute to improving the modelfor the step 118 operating on future HIRQs.

Including process GUI actions at step 134 at this point in the overallprocess of FIGS. 4 a and 4 b provides support for wiki-basedcrowdsourcing of quality control. “Wiki-based crowdsourcing” allowsmultiple trusted users to act on the information (e.g. modify, add,delete, augment, filter) before it is transmitted and/or stored. Changesand authors of those changes are logged to allow for customization (e.g.a Medical Information Source may accept actions of certain users andreject actions of others) and roll-back (e.g. going back to the originalcoding system). In contrast, the current process for quality control inthe health industry is for new documents to be created during eachvisit. These documents contain a snapshot of what a particular providerdescribed as the true state of a patient. The process of constructingthis snapshot usually involves some review of information from previousvisits (e.g. paper chart review, template population in an EHR). Allinformation, true or erroneous, that is added during a visit remains inthe patient's record from that time forward. Mechanisms for one doctorto document comments on or opinions about information contained in aprior chart is typically limited free text comments in a new snapshot,which may or may not be found or connected with the original informationfor future encounters. There is no support for ongoing discussions abouttreatment within the patient's health information documents, though itmay occur via other channels (e.g. telephone, email, face-to-faceconversations between members of the care team). Accordingly, in thissystem quality is improved—errors get removed, system converges on justthat information that stakeholders (members of the care team, etc.) feelis current, accurate and relevant and efficiency is improved—connectingthe dots only needs to happen once, not every time a doctor reviews achart.

The outcome of step 134 is the final HIRSPS, in which information thatmay have been reconciled, translated and/or transformed/optimized mayalso have been filtered, modified, augmented, added, deleted, orcommented via GUI interactions by one or more users.

Exemplary implementations of step 134 include using GUI elements knownin the art and listed above or alternatively, the “DisplayMerge”referred to herein. It is noted that in alternative methods, multipleactions can not be performed and the actions cannot result in changes tothe display, which can then be operated on.

After step 134, the process continues to 122 and after the step 130, theprocess continues to 124.

At 124, a determination is made as to whether or not to return theHIRSPS to Another Specified Entity at step 132. “Another SpecifiedEntity” is an entity such as one included in the source 14. If theresult of this determination is positive, the process continues to thestep 132, otherwise, the process continues to 126. The decision toreturn HIRSPS to the outputs 17, at 124, may be based on an explicitrequest to return an output data object to the outputs 17, or it may beimplied. Implied actions can be identified using algorithms that mayrange from look-up to computational inference via artificialintelligence to advanced machine learning. These algorithms may also becombined serially or in parallel.

At 122, it is determined whether or not the Health Information Response(HIRSPS) should be routed (“returned”) to the source 14. The HIRSPScontains the HIRD after it has been optimized (translated, augmented,filtered and further optimized). The decision to return HIRSPS to thesource 14, at 122, may be based on an explicit request to return anoutput data object to the medical source 14, or it may be implied.Implied actions can be identified using algorithms that may range fromsimple look-up to computational inference via artificial intelligence toadvanced machine learning. These algorithms may also be combinedserially or in parallel.

At step 130, the HIRSPS is returned and the complete request from step120 or step 134 (depending upon the specific flow), is used to assemblea data object according to the instructions contained in HIRQ and theoriginal HIR is returned and the newly created data object is providedto the medical source 14.

The HIRQ portion of the incoming request includes a specification forthe data to be returned to the medical source 14. Previous steps in theprocess carried out translation, augmentation, filtering,transformation, optimization and reconciliation of the data according tothis specification. In step 130, the resulting data is assembled into adata object according to the specification in HIRQ. This data object canbe represented in any number of formats, including but not limited toJSON, XML, standards-based formats such as CCD, CCR and CDA, and otherproprietary formats. The transport mechanism can be web services, IHEprotocols, secure file transfer, proprietary API or any other means totransport a data object.

At step 134, The return HIRSPS to Another Specified Entity of step 132takes as input the complete request from step 120 or 134 (depending uponthe specific flow), assembles a data object according to theinstructions contained in HIRQ and returns the original HIR and thenewly created data object to the outputs 17. The outputs 17, herein, inan exemplary process herein, is another specified entity and not MINE12.

The HIRQ portion of the incoming request includes a specification forthe data to be forwarded to another specified entity (outputs 17.Previous steps in the process carried out translation, augmentation,filtering, transformation, optimization and reconciliation of the dataaccording to this specification. In step 132, the resulting data isassembled into a data object according to the specification in HIRQ.This data object may or may not contain all of the data and querycontents of the original HIR object. For example, it may be required tosend a reconciled list of current problems as computed by the system toa third party, without explicitly including the original data containedin HIR. The data object output to 17 can be represented in any number offormats, including but not limited to JSON, XML, standards-based formatssuch as CCD, CCR and CDA, and other proprietary formats. The transportmechanism can be web services, IHE protocols, secure file transfer,proprietary API or any other means to transport a data object.

At 126, the store HIRQ, HIRSPS and all GUI interactions of step 126 use,as input, the output from the step 124, and store it for future use bythe MINE 12. The specific items stored are the HIRSPS object and the GUIinteractions from step 134 (if any). HIRSPS includes the original queryHIRQ along with the data component HIRD modified by any of thetranslation, augmentation, filtering and reconciliation system stepsthat were performed in the process. Depending upon the specifications ofHIRQ, these can include metatagged information, such as done at step102, or retrieved known data as done at step 106, and concepts as doneat step 106, or reconciled information, as done at step 114, translatedinformation as done at step 116, transformed/optimized codes as done atstep 118, and/or processed GUI actions, as done at step 134. The GUIinteractions are a complete record of all interactions between the userand the GUI. The importance of this information is that it is possibleto apply the same set of translation, transformation, filtering andaugmentation steps that were done by the user in the GUI to data in asubsequent request. Additionally, this information is important forquality control, logging and algorithm improvement purposes.

The actual format and method of storage can include, but is not limitedto, serialized data objects, files, relational database, noSQL or otherkey-value store or any other method that is capable of storing andretrieving this data when needed by the system.

Accordingly, according to one of the processes of FIGS. 4 a and 4 bmedical information, such as HIR, including health information requestquery (HIRQ) and health information request data (HIRD), is received andmetatagged. The metatagged HIR is reconciled based on a semantic conceptand HIRS is returned. An example is a patient with pneumonia wheremultiple occurrences of this condition are noted/coded in various placesand in various forms. These occurrences are found by MINE 12 from thestorage 203 based on the HIRQ or rules and methods about what is to bereconciled and what is desired (problem list).

Although the invention has been described in terms of specificembodiments, it is anticipated that alterations and modificationsthereof will no doubt become apparent to those skilled in the art. It istherefore intended that the following claims be interpreted as coveringall such alterations and modification as fall within the true spirit andscope of the invention.

1. A method of reconciling medical information comprising: Receivinghealth information request (HIR) including health information requestquery (HIRQ) and health information request data (HIRD); Metatagging thereceived HIR; Reconciling the metatagged HIR to map data based on asemantic concept; and Returning the reconciled data.